Multimedia conferencing systems are typically characterized by the following: a directory service which lists the set of conferences; a dynamic mechanism for keeping track of the members of a conference as they join or leave the conference; tools for generating and processing the audio, video and data sharing components of a conference; a data network for interconnecting the members of a conference; and transport mechanisms for distributing the multimedia conference content among the conference members.
Different transport mechanisms can be used to interconnect participants depending on the underlying capabilities of the data network. Two basic communication capabilities are: unicast communication, meaning a point-to-point communication between a source and a destination endpoint; and multicast communication, meaning that one source endpoint reaches multiple destination endpoints. Since conferencing inherently implies the possibility of more than one destination endpoint, if the network is capable only of unicast communication, then either the source must create multiple unicast connections, or Multicast Servers external to the network must be employed. In the former case, each sender of information sets up multiple connections to every receiver, and replicates the data on each connection. Each receiver has multiple incoming connections, one for every sender of information. This approach becomes inefficient as the number of participants (N) gets large for two reasons. Firstly, the number of network connections is proportional to the square of N. Secondly, each endpoint needs to replicate the data N times, possibly leading to both an excessive and unnecessary use of bandwidth in the network and an excessive amount of computation at the source. If external Multicast Servers are employed, then these servers perform the data replication function. Each sender of information needs to have a single unicast connection to the Multicast Server. Each receiver is connected to the Multicast Server. The number of connections is proportional to N, as all senders share the same set of connections to the set of receivers. The disadvantage of this scheme is that the Multicast Server becomes a bottleneck when N gets large.
When the interconnection network is multicast capable, more efficient alternatives are possible. With multicast service, the source of the information sends the data only once--the replication is handled by the network. It is as if the Multicast Servers described in the previous paragraph are bundled into the network. Efficient techniques for replication may exist in the network. For example, the data replication can be performed in hardware, and the replication function can be distributed over the switches or routers of the network. Furthermore the replication topology may be very efficient, e.g. a spanning tree, where receivers are leafs of the tree, and the data source is the root of the tree. Note that it is also possible to use external Multicast Servers in conjunction with a multicast network. For example, the Multicast Server may be connected to the receivers by multicast mechanisms, and to the sources by unicast mechanisms.
The Internet Protocol (IP) is a widely used transport/networking protocol. In the IP Application Programming Interface (API) (known as IP sockets or WINSOCK), application programs may write data to, or read data from a so-called socket just as if the socket was a "file descriptor" on the local computer. A socket is linked to a pair of numbers, i.e. an IP address and a positive integer referred to as a port number. For sending, the IP address used is the destination address to be placed in the destination field IP packet header, and the port number to be used by the application process on a remote machine for receiving the data. For receiving, the IP address is implicitly the local machine address (or in the case of IP multicast, the multicast group address of interest) , and the port number to be used by the application process on the local machine for receiving the data.
Multicast IP, the primary mechanism by which IP networks support multicast, is an emerging capability of the IP protocol. In IP multicast service, unlike the unicast IP service where the address represents a specific and unique end-system, a sender transmits data addressed to an abstraction called a multicast address group. In the prior art, for a given conference, each media-type (e.g., audio, video) is associated with a particular port number and multicast IP address. All receivers for the given media-type listen to the specific socket consisting of the known multicast IP address and port number. All senders for the given media-type send to the specified socket consisting of the same multicast IP address and port number. Among different media-types, a different socket is utilized to enable different application programs to handle the different media of the conference. In prior art systems, the multicast IP address may be the same or different among media types, but the port number is almost always different.
Receivers find out about the existence of multicast groups and port numbers through various (centralized or distributed) directory mechanisms. For example, a well-known multicast IP address may be reserved for directory announcements. Alternatively, a centralized server may contain a list of multicast groups and distribute this list to client terminals upon request. Once the appropriate multicast IP address information has been obtained from the directory mechanism, receivers send messages to Multicast Server processes (e.g., in multicast routers) indicating that they want to join a particular group. The routers then exchange information about the set of users that want to communicate, and build up interconnection trees among themselves. Note that in the prior art, for a given media type, since a common multicast IP address is used by all senders and receivers in a conference, and since the multicast IP address is the atomic unit of routing, this implies that the transmissions of all senders get routed to all receivers, even if each receiver is interested in a (possibly different) subset of the senders. This requires the receiver's application program to receive, process, and discard unwanted information; furthermore the typically expensive network bandwidth required to transport the unwanted information is wasted.
Receivers communicate with multicast routers over some sub-network technology to which both are attached, such as, for example, Ethernet, Frame Relay, or ATM. When IP multicast is supported over a sub-network that has a native multicast ability with a similar service capability to that of IP (e.g., Ethernet), multicast IP addresses may be mapped directly onto Ethernet addresses. Each terminal on the Ethernet then listens for those multicast Ethernet addresses that it is interested in, and ignores the rest.
When IP multicast is supported over a virtual circuit oriented sub-network, such as ATM, that does not have a native multicast capability similar to IP, it is necessary to have an address resolution mechanism to map a multicast IP address into a set of unicast ATM addresses. In the prior art, a Multicast Address Resolution System (MARS) server is utilized for this purpose. When IP receivers want to join an IP multicast group, they send a message to the MARS server. The MARS server then informs all senders to the IP multicast group of the identity of the new receivers. In the prior art, however, a MARS server is only associated with a static set of IP endpoints that are specific to a single sub-network. Thus, if a receiver is a member of a local sub-network, the MARS server specific to that sub-network is used. If conference members are on different sub-networks, one approach of the prior art is to forward multicast IP packets via IP multicast routers connecting the different sub-networks. With respect to the sub-network of which a sender is a member, the multicast router is treated as another receiver by the MARS server of the sender's sub-network. With respect to the sub-networks in which a receiver is a member, the multicast router is treated as a sender by the MARS server of the receiving sub-network. Each sub-network thus requires a separate MARS server and there are no interactions between the plural MARS servers. If it can be assumed that the senders and receivers are attached to a common ATM network, the prior art imposes an extra layer of protocol processing and packet forwarding that introduces additional delays and unnecessary bandwidth utilization. One way of avoiding the use of multicast routers in this context is to allow the MARS servers in the different sub-networks to communicate directly with one another in identifying the ATM addresses of senders and receivers in the different sub-networks. Such multiple MARS servers thus need to communicate with each other for control and coordination purposes, which also requires significant overhead and signaling there between, and the establishment of an inter-server protocol.